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REMARKS/ARGUMENTS 

Claims 1-46 are pending. Claims 5, 12, and 16 were amended to correct typographical 
errors as suggested by the Examiner. 

Applicant acknowledges the Examiner's indication that claims 39-44 are allowable and 
that claims 7-9, 12-23, 27-31, and 35-37 would be allowable if rewritten in independent form 
including all of the limitations of the base claim and any intervening claims. 

The Examiner did not state the status of claim 46. Because no rejections were discussed 
for this claim, Applicant will treat the claim as being allowed. 

The Examiner rejected claims 1, 2, 24, 32 and 33 under 35 USC § 102(a) as being 
anticipated by Jain et al. The Examiner rejected claims 3, 4, 10, 25, 26, 34, 36 and 45 under 35 
USC § 103(a) over Jain in view of Bastiani et aL 

The Examiner states: 

Jain teaches a protocol for devices that format bits in "a frame format (FIG. 2) 
referenced by flowchart of transmitter algorithm, having no requirement for DC 
balance. , . . referenced by asymmetrical DC unbalanced run-length codes. The DC 
unbalanced code inherently has an absence of DC balance in their voltages." 

Applicant respectfully disagrees. 

Jain does not teach, nor have anything to do with, DC balance. A discussion of DC 
balance requires a connection to the mechanism used to transport the bits. A string of bit values 
010101 would appear to be DC balanced while, 100000001 would appear not to be, yet the latter 
string could be DC balanced if a 3 voltage level mechanism or other mechanism is used. What 
Jain did was to recognize that HDLC encoding (more accurately HDLC bit stuffing) is prone to 
error. Specifically, HDLC protocol will take a string of data like "ABCDEFG" and add a header 
character or string: 

<header >ABCDEFG 
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and possibly a trailer character or string (with a CRC check somewhere in the header and trailer): 
<header >ABCDEFG<trailer > 
This then, is the HDLC PROTOCOL level. For transmission, the above string is further 
encoded with a frame delimiter character (which is a hex 0x7e) at the beginning and end of the 
string: 

<0x7e><header >ABCDEFG<trailer><0x7e> 
and everything between the frame delimiters is bit stuffed, which means wherever the bit strings 
(ASCII codes) for data between the delimiters causes there to be 5 'T values in a row, and a 0 is 
added after those 5 'I's. So the only place where 6 Ts occurs is at the frame delimiters. 

Now the problem, if a single bit in the data field changes from 0 to 1 due to noise in 
transmission, it could cause data to look like a frame delimiter (0x7e) and terminate the frame 
unexpectedly. Jain, therefore, extends the frame delimiter character to many more Ts (34) in a 
row 0x7FFFFFFFE. This means many more noise errors would be required in the data in order 
to make data look like a frame delimiter. So framing in this sense is much stronger. But there 
are problems with this, such as a reduction in efficiency, and neglecting to consider 1 to 0 errors 
in the frame delimiter itself. 

So given the above explanation, Jain does not teach DC balance. Jain does not teach 
minimum transition density as required for clock recovery. A string of <frame delimiterxone 
million O'sxframe delimiter> is perfectly legal in Jain, but would not enable clock recovery. 
Jain is not concerned with transmission media, only protocol error detection. Specifically, Jain's 
invention has to be based on serial or parallel buses, with or without clock recovery, and intra or 
inter chassis. 

By comparison, the present invention specifically foregoes DC balance (it primarily 
focuses on intra chassis connections), and focuses on the ability to recover the clock from the 
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from the data stream, guarantees a minimum transition density, and does not have a focus on 
error detection (though it does enable additional error detection capability as a side benefit). 

A combination of Bastiani with Jain also fails teach or suggest the combination of 
features recited in the claimed invention. Both Bastiani and Jain use the term "frame" in a 
different manner from in the present invention. Jain's frame is a series of bits of arbitrary length 
in a stream delineated by a special bit sequence. Jain's frame of bits is a message having a 
specific meaning and protocol, and that message is delivered between two devices/computers 
carrying a complete piece of information than the two computers/devices understand. 

In the present invention, a frame as a very specific, fixed length, and the bits comprising 
the frame do not delineate a single message that could be understood by the two computers or 
devices. For example, in a specific instantiation of the present invention, assume a 'frame' 
consists of 160 bits of data (considering a single serial line implementation for simplicity). Of 
those 160 bits, the first 8 are used for framing information (comprising bit transitions, error 
checks, etc.), and the next 152 bits will be user data. Those 152 bits may include the last x bits 
of the message in the previous frame, a complete y bit length message, and the first z bits of the 
next message. Bits x, y, and z, as well as number of messages within the frame are arbitrary. 
Our framing is a mechanism for carrying bits, it is not related to the message itself (although in 
an optional mode it can). In this example implementation, every single frame is 160 bits long. 
Once the connection id trained during initialization, the system detects the start of a frame by 
counting off 160 bits (clocks), whereas Jain has to count the number of consecutive 1 bit values 
and do some error checking. 

Finally, note that Jain teaches a more robust HDLC bit stuffing technique. In the present 
invention, the message carried using the claimed protocol could be encoded with Jain's method, 
but the system would never know. Jain's is a protocol understood between the computers, 
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whereas the claimed protocol just delivers bits correctly at a physical level. While the present 
invention enables additional services, they are either ancillary, or protocol agnostic and protocol 
unaware. 

In view of the foregoing, it is submitted that claims 1-46 are allowable over the cited 
references. Accordingly, Applicant respectfully requests reconsideration and passage to issue of 
claims 1-46 as now presented. 

Applicant's attorney believes that this application is in condition for allowance. Should 
any unresolved issues remain, Examiner is invited to call Applicant's attorney at the telephone 
number indicated below. 



Respectfully submitted. 



July 21. 2004 
Date 




Attorney for Applicant(s) 
Reg. No. 38,329 
(650) 493-4540 
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